URLs (Uniform Resource Locators) provide a unique and friendly name by which resources on machines (or virtual machines) may be accessed on the Internet. However URLs have limitations that make them less suitable for the growing body of different devices and content becoming available now via networks and the Internet. Some network resources are “unstable content”; they do not naturally persist over time or on a consistent stable set of machines. One example of such content is video taken at a location at a certain time by moving sensors that are no longer at that location; another example is a web cam that is not always turned on. A temperature reading at a certain location taken using mobile sensors is another example of unstable content. Some content may be captured or stored by devices that are not accessible via IP (Internet Protocol) signaling, or they may not be connected to a network at all, and are thus not addressable by URLs. Examples of devices that may not work well with existing URL addressing are sensor packages based on Arduinos or other non-IP network technologies, passive objects with RFID tags, and objects sensed via camera or other sensor, including people.
URLs are also difficult to assign and administer in large numbers. URLs are assigned by explicit human action; someone reserves a friendly name, and then registers the name/address mapping with a DNS (Domain Name Service). As networks expand to cover billions of nodes, this has several shortcomings. One shortcoming is that the URL approach cannot scale as users amass hundreds and thousands of machines in their lives. Consider the new IP (Internet Protocol)-addressable light bulbs. Will users have to come up with unique names for every light bulb in their house? Every electrical socket? Furthermore, the lack of regularity or structure in the assigned names makes it difficult to navigate across the Internet. For instance, what are the URLs for the cameras in the heart of every major American city? Existing schemes for accessing/managing content on the Internet include load balancing, which splits incoming traffic for an IP address across multiple machines. Load balancing typically assumes machines owned by a single provider. This solution virtualizes a resource across multiple IP addresses, but does not address devices that are no longer present at the network address. Another existing Internet scheme involves map products (e.g., Google Maps), which associate data with a specific location, and which again typically assumes machines and content owned by a single provider. There is also an existing technique called URNs, which is an addressing scheme for non-IP objects. This technique is largely ignored, and doesn't provide same programming model for these resources as for internet resources. Non-IP resources cannot be addressed using HTTP GETs and PUTs for instance.
Yet another approach is persistent cloud storage of files by devices. Today a device can store collected sensor information on some cloud service, for example Dropbox, a custom service on AWS (Amazon Web Services), an Internet of Things service such as iDigi, or ThingSpeak. This results however in a large number of URLs to use to access the data, one for each device, and one for the cloud storage for each device. Conventional URLs are assigned by explicit human action, in which someone reserves a friendly name, and then registers the name/address mapping with a DNS. As networks expand to cover billions of nodes, this approach has several shortcomings. Past friendly name approaches like RealNames proposed to provide extensions to URL naming but required changes to DNS services or URL handling in apps and browsers.